[00:00.000 --> 00:05.980]  Hi, welcome everybody. We would like to talk today about a research project we did,
[00:05.980 --> 00:10.400]  Hacking Traffic Lights, and we would like to share our findings and our...
[00:11.200 --> 00:13.800]  well, the things we found in our research.
[00:14.760 --> 00:20.000]  Well, first of all, who are we? My name is Wesley Nele and my colleague's name is Rick van Duin.
[00:20.260 --> 00:25.680]  And we both have been mainly pen testing in the past years for about seven, eight years.
[00:25.680 --> 00:31.320]  And of course, we also have our own interests. For example, I like to play around with Internet
[00:31.320 --> 00:36.200]  of Things and the security of it and innovations like that. And Rick likes to play with malware
[00:36.720 --> 00:43.940]  and investigate that. I would like to... at least one disclaimer, we are no smart traffic experts.
[00:43.940 --> 00:49.760]  We're just, well, two guys that are interested in this kind of innovations. So we decided to use...
[00:49.760 --> 00:54.800]  to do research on it. We do use bicycles because we're Dutch,
[00:54.800 --> 00:59.380]  but that doesn't really help us in our investigation, in our research.
[01:01.320 --> 01:07.920]  Well, a small introduction. Well, what we've seen that there is... they are creating a platform,
[01:07.920 --> 01:12.700]  multiple vendors are creating a platform to exchange information between traffic information.
[01:12.700 --> 01:19.000]  For example, road signs can report die states on a network, the parking spots,
[01:19.000 --> 01:25.680]  how many are still available and how many are occupied. Other traffic status, for example,
[01:25.680 --> 01:31.120]  is there a traffic jam and stuff like that. But they are even trying to connect the traffic lights,
[01:31.120 --> 01:38.560]  the actual traffic light systems to the same network so it can act, well, on the messages
[01:38.560 --> 01:43.820]  that are sent on the network. And one of the examples is that they actually want to connect
[01:43.820 --> 01:50.400]  the road users to the network as well. For example, cyclists, cars, trucks, and even the
[01:50.400 --> 01:56.300]  rescue vehicles, the emergency vehicles. Well, I have to mention that in this research, we mainly
[01:56.300 --> 02:01.740]  have been focusing on the cyclist. And the reason for this is that, well, there was an app available
[02:02.440 --> 02:09.100]  that allows you as a cyclist to install it. And if you're cycling on a road, you will get,
[02:09.100 --> 02:15.620]  well, the time to green will be decreased or maybe even instant green. So, because it was
[02:15.620 --> 02:21.200]  available, we focused on that. Well, important fact is that in the Netherlands, there are a lot
[02:21.200 --> 02:26.980]  of bicycles, 23 million, and we have a lot of cycling infrastructure. So, well, imagine that
[02:26.980 --> 02:33.880]  on every intersection, there's almost a cycling traffic light. So, it's quite important in our
[02:33.880 --> 02:43.780]  country. Well, like said, we've seen multiple apps being released. So, we are mainly interested
[02:44.260 --> 02:49.620]  in the fact that we are able to talk to traffic lights somehow. And for example, how are we able
[02:49.620 --> 02:54.580]  to talk to them? And what if we are able to manipulate it? What is possible? And what can
[02:54.580 --> 03:01.320]  we manipulate? So, that was pretty interesting and the reason why we started the research.
[03:02.280 --> 03:06.860]  Well, one of the things we see in the Netherlands, there's an ongoing partnership.
[03:07.700 --> 03:13.120]  And the goal of that partnership is to realize smart traffic. And the goal is to improve the
[03:13.120 --> 03:19.440]  safety, comfort, and traffic flow. Well, a lot of things are happening in that partnership,
[03:19.440 --> 03:24.440]  but some of the things are, for example, the cyclist app that I was talking about.
[03:24.840 --> 03:30.240]  They are trying to give the user the ability to install an application on its phone.
[03:30.240 --> 03:36.720]  And when he's cycling on an intersection, the cyclist's time will be decreased to go to green,
[03:36.720 --> 03:41.120]  or maybe even instantly go to green if there's no other traffic at the intersection.
[03:41.900 --> 03:49.660]  But another thing is, for example, for trucks. They are trying to realize a green flow on multiple
[03:49.660 --> 03:55.040]  traffic lights. So, the trucks have to stop less, which is, of course, a great idea.
[03:55.600 --> 04:01.940]  And the emergency vehicles, well, that's maybe even the most interesting one,
[04:01.940 --> 04:07.780]  because those will get instantly green if they will be passing a connected traffic light.
[04:07.780 --> 04:15.460]  But also, other users, the road users, will be notified so that there is a vehicle coming,
[04:15.460 --> 04:24.480]  coming up, emergency vehicle. An important thing within the partnership is VRIs. VRIs
[04:24.480 --> 04:30.180]  are the systems that are actually at an intersection that are actually, well,
[04:31.180 --> 04:37.360]  controlling the actual traffic lights. And they are replacing the old systems for intelligent
[04:37.360 --> 04:42.380]  ones, so that it is compatible with the network and that it is possible to communicate to it,
[04:42.380 --> 04:45.840]  but also that it is able to send its own information to the network.
[04:46.060 --> 04:53.480]  And what we've seen that currently about 500 IVRIs or VRIs have been replaced for IVRIs,
[04:53.480 --> 04:58.600]  which is about 10% of the total amount of VRIs.
[05:00.060 --> 05:03.680]  And to give you an idea how the things are connected to each other,
[05:03.680 --> 05:09.680]  on the right, you will see the road users, for example, cars, cyclists, or trucks.
[05:10.300 --> 05:15.760]  And they are, well, connected to the network, for example, by using an app, like I said earlier,
[05:15.760 --> 05:20.260]  but it's also possible that it might be an onboard computer within the truck, for example.
[05:20.260 --> 05:26.740]  And those systems are talking to the, well, to cloud services, which are also like the apps
[05:26.740 --> 05:33.920]  created by multiple vendors. And in the cloud, the information that is sent to the cloud can be sent
[05:33.920 --> 05:39.760]  onto the network. And, for example, to traffic lights. And one of the important things in there
[05:39.760 --> 05:48.940]  is that mostly this is done by using come objects, which is a standard that allows you to,
[05:49.620 --> 05:54.320]  a traffic light network or traffic network. And Rick will be explaining more on that.
[05:54.540 --> 06:00.720]  Cool. So when we initially looked at the first app that allowed users to get a green light,
[06:00.720 --> 06:06.940]  we saw lots of references to come objects. And we saw that the app was building come objects
[06:06.940 --> 06:11.500]  with the position, stuff like that in it. And for us, it was unclear what those were.
[06:11.500 --> 06:17.180]  So we started Googling and we figured out that it's actually a part of the intelligent transport
[06:17.180 --> 06:22.000]  system standard, which is a European standard. There's a different one. As far as we know,
[06:22.000 --> 06:26.180]  there's a different one in the US and it might even be a different one in your country.
[06:27.900 --> 06:34.380]  So important part of this standard are the cooperative awareness messages. So come messages.
[06:35.040 --> 06:41.940]  In the US, they're called basic safety messages. These contain all kinds of information about the
[06:41.940 --> 06:49.220]  intelligent transport system. So it could be a car telling you its speed, stuff like that.
[06:49.760 --> 06:57.520]  So when we looked into the objects itself, we noticed that they contain lots of different
[06:57.520 --> 07:05.160]  information. So we can see the position, what type of vehicle you are. Important to note,
[07:05.160 --> 07:12.320]  later we can see why you shouldn't use the station type to determine what a user is and
[07:12.320 --> 07:18.080]  what they can do. But there's also a different container. So there's a high frequency container,
[07:18.080 --> 07:24.580]  which contains data that changes often. So stuff like data, the direction,
[07:24.580 --> 07:33.660]  information like that. And there's a low frequency container, having data that's more static,
[07:33.660 --> 07:39.020]  such as my lights are on or off, or this was my history, my path history.
[07:40.220 --> 07:49.120]  But more importantly, we came across a special vehicle container. And this container contains
[07:49.120 --> 07:56.500]  information such as I'm transporting dangerous goods, or I'm in emergency vehicle, and I
[07:57.380 --> 08:03.580]  need to have a green light right now, stuff like that. So this for us was the point where we were
[08:03.580 --> 08:08.460]  like, okay, can we manipulate this? And can we send this to the traffic lights that are connected
[08:08.460 --> 08:15.540]  to our apps? Well, when we started looking into this, we actually figured out that the
[08:15.540 --> 08:21.580]  intelligent transport system standard already has a security standard in it. It's based on
[08:21.580 --> 08:29.920]  public key infrastructure, where, very simplified, your vehicle receives a certificate.
[08:29.920 --> 08:35.860]  The certificate contains information about your vehicle and, well, not necessarily your identity,
[08:35.860 --> 08:41.780]  but that you are a vehicle and what you are allowed to do, which allows other systems on
[08:41.780 --> 08:51.200]  the road to actually validate what you are sending to them. So part of the comm messages
[08:51.850 --> 08:59.820]  and the certificate are the SSP and the ITS-AID. So the ITS-AID is the intelligent transport system
[08:59.820 --> 09:05.400]  application ID, and it describes some basic permissions, such as you are allowed to send comm
[09:05.400 --> 09:13.100]  messages. And there's a server-specific permission that's also in there that allows you to
[09:13.100 --> 09:17.940]  actually say, I'm allowed to do this. So for example, I am an emergency vehicle and I'm allowed
[09:17.940 --> 09:26.060]  to tell the world that I need green lights right now. So every message you send out, you sign
[09:26.860 --> 09:33.400]  and it's combined with the certificate in order to let other systems on the road identify that
[09:33.400 --> 09:40.260]  the message you are sending them is actually valid, you are allowed to send it, and that you
[09:40.260 --> 09:47.640]  actually have the correct permissions to request this. So when we were preparing this presentation,
[09:47.640 --> 09:51.420]  we actually came across some interesting work already that's being done on this.
[09:51.420 --> 09:59.740]  So there's a cool paper by Yosef Kamel, which goes on to assume, let's say our authentication
[09:59.740 --> 10:08.240]  authorization is already correct. What can we do with a valid car? So can I say to others,
[10:08.940 --> 10:14.220]  I'm putting on the emergency brakes right now, will other cars immediately start braking?
[10:14.220 --> 10:18.940]  So there's really interesting research being done. There's also some cool software being released
[10:18.940 --> 10:29.280]  in order to look for abuse on the network already. So the security for this exists. However,
[10:29.280 --> 10:35.440]  when we started looking into the apps that Wesley will talk about soon, we noticed that there's
[10:35.440 --> 10:42.500]  still some work to be done. Yeah, like earlier mentioned, we saw multiple
[10:43.120 --> 10:49.800]  well, Android applications that a cyclist could install on his phone. And if he installs it,
[10:49.800 --> 10:56.280]  and he's approaching an intersection, he will get green, the time will be decreased to green,
[10:56.280 --> 11:02.500]  or he will instantly get green. So when we saw that, we were like, okay, what's going on? How
[11:02.500 --> 11:08.900]  does this app work? And what is it exactly doing? And what we did, we did decompile the applications,
[11:08.900 --> 11:15.540]  and we saw that CommonPX were being sent over MQTT. And that was pretty interesting, because
[11:15.540 --> 11:20.260]  if we are able to create those CommonPX ourselves and send it over MQTT, for example,
[11:20.260 --> 11:26.220]  using Python, well, we might be able to trick the system. The thing was, at that time,
[11:26.220 --> 11:32.700]  we didn't know what CommonPX exactly were at that time. So we had quite a hard time imitating the
[11:32.700 --> 11:39.040]  behavior and, well, doing it in Python the same. And also because the ASN and the protobuf encoding
[11:39.040 --> 11:45.760]  that was done by the application. So, well, during that time, we decided to take another approach,
[11:45.760 --> 11:50.920]  and let's use another tool, which was called Frida. And at that time, it was the first time
[11:50.920 --> 11:56.640]  we used it. Well, and it's really an amazing tool. It allows you to, well, hook into an application,
[11:56.640 --> 12:00.940]  for example, an existing Android application that's running on an Android device.
[12:00.940 --> 12:06.120]  And, for example, print the information that's in the function or call other functions and do
[12:06.120 --> 12:13.660]  modifications, for example. So, well, after trying, we were able to print out the CommonPX.
[12:13.820 --> 12:19.700]  And on the right, you can see a snippet of that information. And like Rick was talking about,
[12:19.700 --> 12:24.460]  you see the basic container, the station type, and GPS coordinates. So we were like,
[12:24.460 --> 12:29.420]  this is pretty interesting. What and how the system will react if we are going to manipulate
[12:29.420 --> 12:37.540]  this information? So in order to do so, we also used Frida. And we were able to write a script
[12:37.540 --> 12:43.120]  that's on the left. And what it is doing, it's, again, just hooking before the published com
[12:43.120 --> 12:48.420]  function is being called. So the CommonPX is published on MQTT. But just before that,
[12:48.420 --> 12:54.440]  we modify the information, for example, the speed, the GPS coordinates, and information like that.
[12:54.440 --> 12:59.800]  And our goal was to imitate the behavior that you see in the right, in the image,
[13:00.360 --> 13:05.140]  to let the system believe that there is a cyclist cycling on the intersection all the time,
[13:05.140 --> 13:12.280]  and that in a loop. The thing was, at that time, we were just recognized as one cyclist. And that
[13:12.280 --> 13:18.920]  was, well, we wanted to bypass it. We wanted to be continuously, well, a loop of cyclists that are
[13:18.920 --> 13:26.980]  passing the intersection. So we are trying to bypass that. And well, the way to bypass it was
[13:26.980 --> 13:33.820]  quite simple, because we found out that just before the com is being published, disconnect
[13:33.820 --> 13:39.740]  and connect on the MQTT channel, we are recognized as a different and a new cyclist. So by just
[13:39.740 --> 13:44.560]  disconnecting and connecting, we are able to, just before every CommonPX was being sent,
[13:44.560 --> 13:50.560]  we are able to, well, act like we are a different cyclist instead of one. So that was cool. We
[13:50.560 --> 13:57.960]  were able to, well, get that flow continuously. Later on, we found another, a similar application,
[13:57.960 --> 14:02.880]  which is also an application. And if you install it as a cyclist, you will get, well, the time
[14:02.880 --> 14:08.500]  will be decreased, or you will instantly get green, depending on the situation at the intersection.
[14:08.940 --> 14:13.620]  But this application was even easier, because it was just sending one post request.
[14:13.620 --> 14:19.800]  As you can see in the slide, with similar information that we saw in the previous app,
[14:19.800 --> 14:25.540]  like speed, GPS coordinates, and information like that, also the station type.
[14:26.300 --> 14:32.680]  And that was being sent to the server. So somehow, this is probably converted, for example,
[14:32.680 --> 14:38.600]  to come by the backend. So we didn't have to take care of that at all. We just have to send one post
[14:38.600 --> 14:43.500]  and the system will react on it. And the interesting thing, there was no authentication.
[14:43.500 --> 14:48.680]  So there's no way to distinguish a cyclist from each other within the system. And that was quite
[14:48.680 --> 14:56.660]  an interesting part, because maybe we can, well, fake a lot of cyclists in the city, for example.
[14:57.120 --> 15:01.600]  Well, we wrote a Python script to just send this post with the correct information.
[15:02.200 --> 15:06.840]  And, well, we recorded the demo on it, and I would like to show the demo.
[15:07.340 --> 15:13.020]  Here you will see a video where we are at a traffic light, a connected traffic light on
[15:13.020 --> 15:18.420]  an intersection. And in this video, there is other traffic at the intersection. And you will see that
[15:18.420 --> 15:24.940]  the system reacts and the waiting sign turns on. But, well, it will wait until it goes to green,
[15:24.940 --> 15:30.920]  well, when it's safe. So that's quite important to note. The safety system stays intact. So it
[15:30.920 --> 15:37.740]  will never turn two lights at green at the same time. So that's lucky and good that that's still
[15:38.240 --> 15:45.180]  in place. Also, we recorded a second video, also at a traffic light, but in this case,
[15:45.180 --> 15:50.280]  without any other traffic. And as you can see, well, it reacts quite quickly and instantly.
[15:50.280 --> 15:58.800]  If we send one post request, the system instantly turns to green. So it just goes quite quickly.
[15:58.800 --> 16:04.960]  So what could we do with this vulnerability? Well, it's abusive functionality, but,
[16:04.960 --> 16:10.260]  well, like we mentioned, it is not able to see multiple cyclists. It's just,
[16:10.260 --> 16:16.200]  well, using every request and doing an action on that. So what we could do is use the previous
[16:16.200 --> 16:23.100]  script and do it on a lot of traffic lights at the same time, because that system was running
[16:23.100 --> 16:31.500]  in 10 cities currently. So you could just interrupt the traffic in a complete city at the
[16:31.500 --> 16:44.260]  time. So in conclusion, I think the place we are now is that there's no real use of the security
[16:44.260 --> 16:50.340]  part of the standard. They are using cooperative awareness messages to determine where vehicles
[16:50.340 --> 16:56.060]  are, but there's no clear distinction on what they are, who you are, or if you're even authorized
[16:56.060 --> 17:05.160]  to do so. Luckily now we're working with the public betas where cyclists are being used,
[17:05.160 --> 17:12.420]  but there are some closed betas going on for trucks, for emergency vehicles, and especially
[17:12.420 --> 17:22.900]  those could pose a real threat for traffic. Luckily security systems will stay intact,
[17:22.900 --> 17:27.820]  so there's no hacker style, all the lights green at the same time, cars hitting each other,
[17:27.820 --> 17:35.680]  stuff like that. So just currently we're able to annoy you, which is already fun.
[17:37.740 --> 17:42.260]  So the reason we're giving this presentation is we really believe that
[17:43.460 --> 17:48.300]  this is something that's coming and we need to be sure that this is actually working properly,
[17:48.300 --> 17:54.580]  meaning that authentication and authorization are correctly implemented. We've seen it with email,
[17:54.580 --> 18:00.100]  we're still having issues determining if a mail you've received is actually from the person you
[18:00.100 --> 18:05.800]  received it from. And so it's really important that the moment our physical lives, the traffic
[18:05.800 --> 18:11.820]  is being controlled by these systems, that this is something that's actually properly working.
[18:13.680 --> 18:20.980]  So we would recommend that these apps will start to use some form of authentication,
[18:20.980 --> 18:26.660]  at least knowing that there's one person operating one app. If they choose to spoof
[18:26.660 --> 18:32.860]  whatever it is they do, at least we would know they would only be able to control one
[18:33.620 --> 18:40.420]  digital cyclist. And it's becoming more and more important to detect and monitor abuse on
[18:40.420 --> 18:45.980]  the back end of things, meaning that the central system receiving all these messages and distributing
[18:45.980 --> 18:52.960]  them to the different traffic lights would need to look for unexpected or implausible behavior
[18:53.760 --> 19:01.360]  and block users accordingly, which would reduce the impact of somebody trying to manipulate this.
[19:01.360 --> 19:07.620]  And I mean after that, if the moment we have the authentication and authorization under control,
[19:07.620 --> 19:14.960]  we will have to see and look into abuse from a allowed user. But that's the next step.
[19:15.080 --> 19:22.940]  So this is as much as our presentation encompasses. If you have any questions and you want to join in
[19:22.940 --> 19:30.520]  Q&A, it will be on the 6th of August between 1.30 and 2 o'clock. Or if you need to contact us
[19:30.520 --> 19:34.840]  directly, check it out on Twitter. Thank you. Thank you.
